Частина 1. Вступ
— Частина 1. Вступ
— Частина 2. Загальна структура
— Частина 3. Первинні ланцюжки
— Частина 4. Адміністратор даних
— Частина 5. Адміністратор процесів
— Частина 6. Структура застосунку
— Частина 7. Публікація в GCP
Модулі підприємства
SYNRC Підприємство є комплекском бібліотек (N2O.DEV) та підсистем застосунків (ERP.UNO), яке використовує загальну шину та загальну розподілену базу даних.
LDAP — Сервер аутентифікації, зберігання ключів та директорія підприємства.
ERP — Цей модуль зберігає основну ієрархічну структуру підприємства, її схему, записи про персонал, інвентар, компанії та офіси підприємства.
FIN — Фінансовий модуль підприємства, який зберігає бізнес процеси, що являють собою рахунки учасників системи: персонал (для нарахування зарплат), рахунки та субрахунки підприємства (для здійснення економічної діяльності) та зовнішні рахунки в платіжних системах.
ACC — Система управління персоналом: зарплатні відомості, календар підприємства, відпустки, декрети та інші календарі.
SCM — Система управління ланцюжком поставок: головний БП системи - експедиційний процес доставки товарів ланцюжку одержувачів за допомогою транспортних компаній.
CRM — Система управління клієнтами: є розширенням більш абстрактного застосунку CHAT.
PLM — Система управління життєвим циклом проектів та продуктів. Містить також CashFlow та P&L звіт.
PM — Система управління проектами підприємства із деталізацією часу та протоколів приймання-передачі (прийняті комміти у гітхабі).
WMS — Система керування складом.
TMS — Система керування транспортом підприємства.
Модуль PLM
У цьому документі описано систему управління життєвим циклом продуктів та проектів - Product Lifecycle Management (PLM). На базі PLM модуля ми розробили систему керування аутсорсинговим підприємством Quanterall із можливістю інвестування і врахуванням опціонів для програмістів.
Цілі проекту:
— Підвищення прозорості ведення бізнесу;
— Видача опціонів із прибутку;
— Автоматизація підприємства.
Задачі проекту:
— Створення панелі управління директора, працівників та інвесторів;
— Попроектна звітність (СashFlow, P&L);
— Управління опціонами програмістів;
— Інвестування в проекти іншими інвесторами (зі страхуванням).
Бізнес процеси:
— Бізнес-процес рахунок учасника проекту (FIN);
— Головний бізнес-процес модуля - довгоживучий проект-продукт (PLM);
— Створення проекту із залученням інвестицій під заставу прибутку від інших проектів (Pre-PLM);
— Щомісячний процес розподілу прибутку (PLM-Calc):
після віднімання згортки виплачених зарплат із згортки оплачених рахунків клієнтам
по CashFlow ми формуємо список статей:
1) страховий фонд (який відкушується якщо ми використовуємо цей проект
як заставу для кредиту на інший проект);
2) опціони програмістів
видаються автоматично людям, які працюють на цьому проекті,
таким же чином будь-які інші можуть також брати участь;
3) наш заробіток (вільний пул чи резервація);
4) R&D відрахування (обов'язкові).
Керівництво розробника PLM
Посібник розробника PLM включає покроковий опис процесу створення підсистеми PLM та використання бібліотек SYNRC: 1) Адміністративна частина KVS, BPE, FORM; 2) Модулі конфігураціїи PLM: PLM, FIN, LDAP.
Система PLM залежить також від інших моделей підприємства: FIN — фінансовий модуль управління персональними рахунками та рахунками підприємства; ACC — модуль управління персоналом та контрагентамии; ERP — модуль інкапсуляції організаційної структури підприємства; LDAP — система управління ідентифікаторами та ключами. Окрім модулів підприємства тут також розглядаються бібліотеки, залежності модуля PLM: BPE — система управління бізнес процесами підприємства; KVS — система зберігання данних; FORM — система генерації форм. PLM залежить і від інших бібліотек, але вони у цьому документі не розглядаються: N2O — система управління з'єднаннями та протоколами; NITRO — система генерація HTML5.
Управління ресурсами
Головним чином інформаційна структура нашого підприємства складається з обчислювальних ресурсів (додатки запущені в шині) та накопичених ресурсів (дані збережені у базі даних).
SOA архітектура як модель управління обчислювальними ресурсами пропонує асинхронний протокол віддаленого виклику на шинах. З N2O можна використати MQTT та інші шини за допомогою наступних протоколів: TCP, WebSocket. Ще ці асинхронні протоколи часто називаються протоколами реального часу, оскільки функції надсилання повідомлень завжди миттєво повертають результат. Щодо протоколів для публікації та доступу до даних тут може виявитися доречним використання синхронного HTTP протоколу.
Обчислювальні ресурси
Для SOA архітектури традиційно використовуються асинхронні протоколи доступу до обчислювальних ресурсів. Зазвичай це серверні воркери підключені до шини та обслуговуюче API певного застосунку. Кожна програма має своє консистентне хеш-кільце воркерів. В мережі працює одночасно безліч кілець-застосунків.
За допомогою config.exs файлу можна налаштувати необхідну конфігурацію серії консистентних кілець, кожне з яких працює на своєму транспортному протоколі. У цьому прикладі показана карта Erlang серверів, які обслуговують черги застосунків у шині:
Завдяки такій деталізації можна проектувати гетерогенні системи включаючи необхідний набір протоколів на портах необхідних для цього машин. Ця ж система дозволяє досягти балансування у навантаженні, включаючи фізичні ресурси до певних черг шини даних.
У нашій моделі асинхронні протоколи використовуються для керування обчислювальними ресурсами підприємства.
Накопичувальні ресурси
Розподілені хеш-кільця використовуються не тільки для розподілу обчислень, але й для зберігання даних. Деякі бази даних, наприклад RocksDB та Cassandra використовують глобальний простір ключів для даних на відміну від таблично-орієнтованих баз. Саме для таких баз і створена бібліотека KVS, в якому як синхронний транзакційний інтерфейсу являється API ланцюжків з гарантією консистентності. У цьому прикладі показаний приклад структури ланцюжків екземпляра системи PLM:
У нашій моделі синхронні протоколи використовуються для керування накопичувальними ресурсами підприємства та транзакційного процесингу.
Типові специфікації
Протоколи визначаються типовими специфікаціями та генеруються для наступних мов: Java, Swift, JavaScript, Google Protobuf V3, ASN.1. Також ми генеруємо валідатори даних, за цими типовими анотаціями та вбудовуємо ці валідатори в тракт наших розподілених протоколів, тому ми ніколи не дозволяємо клієнтам зіпсувати сторадж. Для веб-застосунків у нас розвинена система валідації як JavaScript, так і на стороні сервера. Бізнес логіка повністю ізольована в нашій системі управління бізнес процесами, де кожен бізнес процес є процесом віртуальної машини. Усі ланцюжки модифікуються атомарним чином, підтримують flake адресацію та не вимагають додаткової ізоляції у своєму примітивному використанні. Тому ви також можете трактувати базу як розподілений кеш, і використовувати її з фронту застосунків для примітивних випадків.